home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / newsgroups / misc.19951130-19960209 / 000302_news@columbia.edu _Fri Jan 19 10:00:38 1996.msg < prev    next >
Internet Message Format  |  2020-01-01  |  4KB

  1. Return-Path: news@columbia.edu
  2. Received: from apakabar.cc.columbia.edu (apakabar.cc.columbia.edu [128.59.35.159]) by watsun.cc.columbia.edu (8.7.3/8.7.3) with ESMTP id KAA17396 for <kermit.misc@watsun>; Fri, 19 Jan 1996 10:00:37 -0500 (EST)
  3. Received: (from news@localhost) by apakabar.cc.columbia.edu (8.7.3/8.7.3) id KAA04602 for kermit.misc@watsun; Fri, 19 Jan 1996 10:00:35 -0500 (EST)
  4. Path: news.columbia.edu!watsun.cc.columbia.edu!fdc
  5. From: fdc@watsun.cc.columbia.edu (Frank da Cruz)
  6. Newsgroups: comp.protocols.kermit.misc
  7. Subject: Re: File transfer through a third machine.
  8. Date: 19 Jan 1996 15:00:26 GMT
  9. Organization: Columbia University
  10. Lines: 51
  11. Message-ID: <4dobma$4eh@apakabar.cc.columbia.edu>
  12. References: <DLD12n.27p@scisun.sci.ccny.cuny.edu>
  13. NNTP-Posting-Host: watsun.cc.columbia.edu
  14.  
  15. In article <DLD12n.27p@scisun.sci.ccny.cuny.edu>,
  16. Hua Deng <deng@scisun.sci.ccny.cuny.edu> wrote:
  17. : I have some problem to transfer files from a PC (running K95) through a
  18. : modem connected to a VAX(VMS), which in turn is telneted to a unix
  19. : running C-kermit 5A(190). The transfer from unix to PC is OK (with
  20. : 1.3kcps rate on a 14.4 connection) but the transfer from PC to unix is
  21. : very poor with low packet-length (60 cps with lots of errors)and does
  22. : not work at all with large (~500) packet length.Is there anything I can
  23. : do to speed up the transfer? sz does not work in either direction in k95
  24. : or other program such as hyperterminal.
  25. Because Telnet on VMS is filtering out certain characters, perhaps even
  26. all 8-bit characters.  This is exactly the kind of cranky connection that
  27. Kermit protocol is good at pushing its way through, so the problem is how
  28. to make it go faster.
  29.  
  30. At first glance, this looks like a flow-control problem.  Is the modem on
  31. the VAX end plugged directly into a VAX serial port?  A terminal server?
  32. In any case, you have to examine the flow-control setup between the modem
  33. and the thing it is directly attached to, and also the buffering
  34. configuration of the "thing" (terminal server, LAT box, or VMS itself).
  35.  
  36. You might have better luck using Kermit Telnet on VMS than VMS Telnet
  37. itself (UCX, TGV, Wollongong, or whatever you have).  Tell it to "set
  38. command byte 8" and "set term byte 8" and "set flow xon/xoff".  The latter
  39. is not really Xon/Xoff, but results in the equivalent of VMS SET TERM
  40. /HOSTSYNC /TTSYNC, which, on a TCP/IP connection simply means "don't drop
  41. TCP packets on the floor" :-)   VMS C-Kermit -- current version 5A(190) --
  42. also selects the terminal's Alt-Typeahead buffers, which are bigger than
  43. the regular ones.
  44.  
  45. Having said all that, there is still the limiting factor of pumping
  46. massive amounts of data into any VMS Telnet program, Kermit or otherwise.
  47. Experiments here show approximately the same results as yours, no matter
  48. whether I use Kermit Telnet or regular (UCX) Telnet on VMS, or even
  49. rlogin -- which doesn't work at all unless I say RLOGIN /ESCAPE="" <host>.
  50. (This paragraph applies if you have a TELNET connection from, say, a
  51. terminal server into VMS.)
  52.  
  53. If I substitute UNIX for VMS as the intermediate system I get better
  54. results, by about 400%, not that this is of any help to you.
  55.  
  56. So yes, you can upload files through this type of connection using Kermit,
  57. but if it's something that you need to do all the time and none of the
  58. above hints help, it would be better if you could make a less roundabout
  59. connection.  Another alternative to consider would be to transfer the file
  60. in two stages.  If you write a script to automate this, it would probably
  61. take a lot less elapsed time to upload the file in two stages than it is
  62. taking now to upload it in one.
  63.  
  64. - Frank